Jonas Dreßler [Wed, 21 Aug 2019 14:47:38 +0000 (16:47 +0200)]
pieTimer: Use custom GObject property for animating pie
Before the move to Clutters implicit animations with 0846238f6 and bf497ed64, we used Tweener to do a fake-animation of the opacity and
Tweeners `onUpdate` signal to queue a repaint of the PieTimer everytime
Tweener tries to update the animation.
Now, with Clutters implicit animations, there is no `onUpdate` signal
anymore and also `notify::opacity` no longer gets emitted since the
value doesn't actually change. This lead to the PieTimer no longer being
repainted, which broke the animation.
Fix this by implementing the current angle of the pie using a custom
GObject property `angle` and animating this property using the new
`actor.ease_property` method.
Jonas Dreßler [Thu, 8 Aug 2019 22:15:48 +0000 (00:15 +0200)]
iconGrid: Restore grid actors when cancelling animations
When cancelling the animations of the icon grid, right now we simply
destroy all the clones without resetting the opacity and making the
actor reactive again. So if the spring animation to show the grid is
cancelled by pressing a key to start a search, the icon clones would be
destroyed, but the icon-opacity would still be set to 0. Now if the
Escape key is pressed, viewSelector will show the last active page (ie.
the iconGrid) without a custom animation and only fade in the page, and
because the icons still have an opacity of 0, they will be invisible.
Fix this by always restoring the opacity and reactive property of the
original actors if the animation is cancelled instead of only destroying
the clones.
Florian Müllner [Mon, 12 Aug 2019 12:10:43 +0000 (14:10 +0200)]
brightness: Ignore slider changes we initiated ourselves
Since we set the proxy value when the slider changes and set the slider
value on proxy property changes, we run into a cycle.
Before commit 3d3dca4aa this was addressed by not notifying on all slider
changes, but only in reaction to direct user action. Given that since the
splitting out of the BarLevel class those events are handled in a subclass,
that approach is at least unconvential and fairly fragile.
Instead, make the brightness indicator ignore any changes to the slider it
initiated itself.
Jonas Dreßler [Thu, 8 Aug 2019 19:09:06 +0000 (21:09 +0200)]
viewSelector: Use onStopped callback when fading out pages
With 8b368d010 we fixed a bug where the onComplete callback was always
called no matter whether the transition was interrupted before or not.
This exposed another bug: viewSelector depends on this behaviour when
fading out pages: After fading out a page, we call `this._animateIn` to
show the new page. Now if the fade-out animation gets interrupted, with
the correct behaviour of onComplete we end up not showing a new page and
the viewSelector remains empty instead. One case where this happens is
when pressing a key to start a search during the overview-animation.
Obviously we also want to show the new page in case the fade-out
animation was interrupted, so use the onStopped callback instead of the
onComplete callback here.
When a drag is cancelled and the source actor
is visible, the drag actor is animated back to
the source position. The scale that the drag
actor will become is calculated as:
scale = this._dragActor.width / sourceScaledWidth
However, this is wrong; what we wanted to do
is the opposite:
scale = sourceScaledWidth / this._dragActor.width
Fix the scale calculation to match the math
above.
Because the Dash icons are not drop targets themselves,
add a tiny DashIcon class, which is an AppDisplay.AppIcon
subclass, and disable all DND drop code from it.
Show a folder preview when dragging an app icon over another
app icon.
As per design direction, scale and fade the app icon
when starting dragging it, and show it again if the
drop is accepted. Clutter takes care of animating the
rest of icon positions through implicit animations.
Scale and fade the dragged icon while it's being dragged.
Jonas Dreßler [Wed, 7 Aug 2019 15:39:25 +0000 (17:39 +0200)]
search: Defer updating results on allocation changes until redraw
Since the `notify::allocation` signal will obviously get emitted while
the actor is inside an allocation cycle and we might end up doing
changes to its allocation inside `updateSearch` by hiding or showing the
actor (which queues a relayout), we get a warning from Clutter.
Fix this by delaying the call to the parent method until the next
redraw, which should happen a few moments after the current relayout.
Jonas Dreßler [Wed, 7 Aug 2019 14:42:17 +0000 (16:42 +0200)]
search: Don't use max number of results if allocation width is 0
Since commit 1a27ff6130e03e64d9e426ece72a12e4e2a80f50 we use the
allocation width of the GridSearchResults actor to calculate the max
number of results that can be shown for this search provider.
On the first run of the search, when no previous (cached) allocation is
available for the actor of GridSearchResults, the allocation width used
in `_getMaxDisplayedResults` will be 0, which in turn will make
`updateSearch` filter out all results returned by the search provider.
Now if this search provider is the only search provider that's enabled,
after calling `updateSearch`, the `SearchResults` class will call
`_updateSearchProgress` to check if any results are visible, assume
nothing was found and therefore hide the scrollView. This in turn causes
the GridSearchResults actor to not get a new allocation, which prevents
our code to fixup the max number of results on `notify::allocation` from
working: The number will continue to be 0 and we'll never show any
results.
To fix this regression, return -1 in `_getMaxDisplayedResults` if the
allocation width is 0 to inform `updateSearch` that we can't calculate
the maximum number yet and interpret a return value of -1 as "show all
results" in `updateSearch`. The same problem would probably also appear
if the allocation width is anything between 0 and the width of the
iconGrid with one icon in it, although this might as well be a valid
width in case a very small screen is used or with very large icons. So
let's only check for a width of 0 and hope the GridSearchResults actor
won't get weird temporary allocations in that range.
Jonas Dreßler [Thu, 8 Aug 2019 16:15:32 +0000 (18:15 +0200)]
appDisplay: Animate activate-discrete-gpu action in the AppIconMenu
Just as we animate the apps launch using the zoom out animation if the
'new-window' action provided by the app is launched, we should also show
this animation if the 'activate-discrete-gpu' action provided by the app
via its AppInfo is launched.
Jonas Dreßler [Thu, 8 Aug 2019 15:27:40 +0000 (17:27 +0200)]
appDisplay: Always animate our own new window and discrete gpu actions
For the "New Window" entry we add to the AppIcons popup menu we should
always animate the app icon if the menu entry is activated as it was
intended by commit 62786c09a8.
For the "Launch using Dedicated Graphics Card" entry we can also always
show the animation if the entry is activated since the entry should only
be visible if the app is stopped.
Clocks has exactly the same issue as Weather: Its integration currently
relies on accessing its settings directly, which isn't possible when
the app is sandboxed.
Fix this the same way we did for Weather, by adding our own setting
and syncing it with the app via a custom D-Bus interface.
Jonas Dreßler [Fri, 2 Aug 2019 12:23:13 +0000 (14:23 +0200)]
appDisplay: Animate launch of new-window action in the AppIconMenu
We add our own "New Window" menu entry if the app doesn't already
provide a 'new-window' action. For this menu entry, we show the zoom out
animation on the app icon when the user clicks the entry.
To be consistent in case the app already provides its own 'new-window'
action via its AppInfo, also show the zoom out animation when this
action is activated.
Whenever an app is installed, the usual routine is
to run 'gtk-update-icon-cache' after installing all
of the app's files.
The side effect of that is that the .desktop file of
the application is installed before the icon theme
is updated. By the time GAppInfoMonitor emits the
'changed' signal, the icon theme is not yet updated,
leading to StIcon use the fallback icon.
Under some circumstances (e.g. on very slow spinning
disks) the app icon is never actually loaded, and we
see the fallback icon forever.
Monitor the icon theme for changes when an app is
installed. Try as many as 6 times before giving up
on detecting an icon theme update.
The texture cache, right now, only monitors for
complete theme changes. If the contents of the
icon theme change, however, the texture cache
isn't properly invalidated.
This manifests itself as a randomly reproducible
bug when installing an app; the app icon may be
the fallback forever, or as long as something else
updates the icon theme.
Watch for the GtkIconTheme:changed signal, and
evict the texture cache when the theme changes.
allView: Remove icon from folder when dropping outside
When dropping an app icon to outside the folder, remove the
app from that folder. GNOME Shell is already smart enough
to figure out the setting changes and update the icons.
Connect to the overview signals related to Drag n' Drop, and
allow dropping application icons in it. Dropping an icon
appends the application id to the folder's GSettings key.
The event blocker is an actor that is added in between the
icon grid and the app folder popup in order to guarantee
that clicking outside the app folder will collapse it.
However, the next patch will require allowing dragging events
to be passed to folder icons, and the event blocker gets in
our way here, preventing drag n' drop to work properly.
Add an API to inhibit the event blocker. This API will be
used by the app folders while an item is dragged.
Florian Müllner [Sat, 15 Jun 2019 14:31:53 +0000 (16:31 +0200)]
systemActions: Create SensorProxy unconditionally
When plugging in a device with sensors that are unsupported by
iio-sensor-proxy, the proxy may quit so fast that the name disappears
from the bus before we get to construct the SensorProxy in response
to the name-appeared handler, resulting in the following warning:
JS ERROR: TypeError: this._sensorProxy is null
_sensorProxyAppeared/this._sensorProxy<@resource:///org/gnome/shell/misc/systemActions.js:217:17
_makeProxyWrapper/</<@resource:///org/gnome/gjs/modules/overrides/Gio.js:243:21
Address this by creating the proxy unconditionally instead of monitoring
the bus name, and using the g-name-owner property to determine whether
iio-sensor-proxy is active.
Sergey Bugaev [Sat, 20 Oct 2018 13:28:05 +0000 (16:28 +0300)]
workspace: Sort windows to minimize travel distance
When transitioning to or from the overview, windows travel
a certain distance between their real desktop position and
their place in the overview window grid. The less this travel
distance is, the smoother, more polished, and less jarring
the overall transition looks. This is why it makes sense to
try reordering and repositioning windows to minimize their
travel distance. That being said, there are other factors
that impact the quality of the overview layout, such as how
much the windows get scaled and what portion of the overall
available space they take up.
The existing code tries to minimize the travel distance by
sorting the windows in each row by their horizontal position.
There are, however, two problems with this implementation.
First, it compares the coordinates of windows' left edges as
opposed to their centers, which means it yields unexpected
results when a small window is positioned next to the left
edge of a large window. Second, it completely disregards
vertical coordinates, instead assigning windows to the grid
rows using their monotonically increasing window numbers,
effectively vertically sorting them by the order they were
created in.
This commit changes both vertical and horizontal ordering
to work based on the coordinates of the geometric centers
of the windows. That is to say, windows are first assigned
to grid rows based on the vertical coordinates of their
centers, and subsequently sorted inside each row based on
the horizontal coordinates of said centers. In my testing,
this leads to a much more intuitive and visually pleasing
window placement.
GDBusProxy::g-properties-changed is also emitted when the name drops from
the bus, at which point any properties will be null. That's not a valid
gsettings value, so to avoid the corresponding warning, move the g-name-owner
check accordingly.
Those checks were carried over from the very first DND implementation;
if they were ever actually required at all, this is no longer the case
as we moved away from Tweener for all our animations.
The number of cases where an extension is still using Tweener, creates
draggable actors, *AND* requires the checks for proper functioning
should be indistinguishable from zero, so drop the code.
environment: Add convenience method for adjustment transitions
By now, Tweener is used exclusively to animate changes to the
StAdjustment:value property. But not for long, as now that we
implement the same transition API as Clutter.Actor, we can
re-use the existing convenience method for property transitions
for adjustment changes as well.
Florian Müllner [Fri, 2 Aug 2019 14:58:39 +0000 (16:58 +0200)]
st: Add transition API to StAdjustment
StAdjustment implements the ClutterAnimatable interface, so we can
already animate its properties with ClutterPropertyTransitions.
But as it is currently not possible to associate a transition with
an adjustment, it must be owned (and kept alive in case of GC) by
the calling code.
Change that by implementing the same (add|remove|get)_transition() API
as ClutterActor, so we can use a familiar API and even duck typing in
case of javascript.
Florian Müllner [Wed, 7 Aug 2019 00:28:40 +0000 (02:28 +0200)]
environment: Remove transition tracking
The tracking was important in an earlier iteration, but as the helper
functions now remove overwritten transitions before setting up the
new ones, we can just as well connect to the ::stopped signal directly.
Florian Müllner [Wed, 7 Aug 2019 00:26:32 +0000 (02:26 +0200)]
environment: Fix transition callback
This is rather embarrassing - we currently confuse the transition with
the finished parameter, which means we always run the onComplete handler
no matter whether the transition was interrupted or actually completed.
Commit 0f178c3b3dcfe added a shortcirtuit to avoid running
an animation on an invisible actor. However, it introduced
a bug where the current page is not properly updated. That
leads to the wrong set of icons being animated under some
circumstances.
Update the current page even if we bail out early.
Properties that aren't marked as animatable don't support *implicit*
animations, but they can still be animated with explicit transitions.
Use the newly added convenience method to cut down further on Tweener
usage.
Florian Müllner [Sat, 10 Jun 2017 02:14:12 +0000 (04:14 +0200)]
environment: Add convenience method for property transitions
While we are now using implicit animations for all animatable properties,
there are still some cases where we animate other actor properties (for
example from a custom subclass) or associated objects like effects.
Those can still be animated using Clutter animations, as long as we use
the explicit API rather than implicit animations. Again this API is
cumbersome and tricky enough to warrant a convenience wrapper.
js: Use GObject properties for animated properties
Clutter animations work on GObject properties on animatables. The
last commit took care of the latter by turning all animated objects
into actor subclasses, now it's time to make all properties used
in Tweens into GObject properties.
We have a couple of places where we don't tween the actor, but a
custom property on the delegate object. In order to move those
to Clutter animations, we will need an animatable, so turn those
objects into widget subclasses.
The set_brightness() method is the most convenient way of controlling
the effect's brightness, but Clutter animations only deal with properties,
so start using the (ClutterColor) brightness property instead.
Currently WindowDimmer exposes a JS property that is used to control the
underlying effect. This works fine with Tweener, but not with Clutter
animations which we want to use ultimately.
As a first step towards that, expose a setDimmed() method instead of
the property and handle the animation internally, so it can be adapted
more easily.
Florian Müllner [Sat, 10 Jun 2017 00:52:12 +0000 (02:52 +0200)]
environment: Add convenience method for implicit animations
Setting up implicit animations is more verbose than using tweener, in
particular when setting up a callbacks to run on overwrite or completion.
In order to make its use more convenient, monkey-patch ClutterActor
with an ease() method that works similarly to Tweener.addTween().
Florian Müllner [Wed, 4 Jun 2014 22:13:14 +0000 (00:13 +0200)]
environment: Support slow down factor when easing
Being able to slow down animations is a helpful debugging tool; to not
lose it when starting to use Clutter's implicit animations, monkey-patch
the appropriate methods to support our global slow down factor.
Florian Müllner [Wed, 4 Jun 2014 22:13:14 +0000 (00:13 +0200)]
environment: Add adjustAnimationTime() helper
As we currently use Tweener for all animations, we have a single place
for hooking up the enable-animations and slow-down-factor settings.
However that will no longer hold true when we'll start to use Clutter's
built-in animation facilities, so add a small helper function that
applies the necessary adjustments.
Notifications use a transition that overshoots the target value, however
we can only really do that for the position and not the opacity where
some values would end up out of the valid range.
We currently address this by proxying the actual opacity property in a
javascript property, and clamp it to the valid range in an onUpdate()
callback.
This won't be an option if we want to use Clutter animations, so instead,
use separate tweens for opacity and position.
Florian Müllner [Sun, 4 Aug 2019 23:02:38 +0000 (01:02 +0200)]
pageIndicators: Defer IN animation until redraw
Unlike Tweener, which doesn't know or care about actor state, Clutter
will skip implicit animations on actors that aren't mapped. This makes
sense of course, but it will break the page indicator animation we
do on map: When we get notified about the container being mapped, the
individual indicators (which are the actors being animated) are still
unmapped.
Resolve this by deferring the animation to a LaterFunc.
For animating the arrows on the screenshield, we currently use a custom
transition function that tweens the opacity from 0 to maxOpacity in the
first half of the animation, and from maxOpacity back to 0 in the second
half.
This doesn't easily translate to Clutter's own animation framework, so
replace the custom transition with two consecutive tweens which do.
Dash items are currently animated via the custom "childScale" and
"childOpacity" properties. However since commit efb3025d8cdb, those
properties actually control the scale-x/scale-y and opacity properties
of the actor itself (not the child), so cut out the intermediate
custom properties in favor of the "real" ones.
Florian Müllner [Sat, 10 Jun 2017 02:32:22 +0000 (04:32 +0200)]
popupMenu: Split submenu expansion and arrow rotation
When expanding a submenu, we currently use a single tween to animate
both the submenu actor and the source arrow. We do this by tweening
a monkey-patched JS property on the main actor, which we then use
to update the arrow's GObject property on updates. As Clutter cannot
animate random JS properties, this trick will prevent us from using
implicit animations here.
The only reason I can think of for using a single tween is to keep
both animations in perfect lock step, but as expansion and rotation
are visually quite distinct, this shouldn't be required, so just
set up separate animations for each actor.
Florian Müllner [Tue, 6 Aug 2019 11:19:59 +0000 (13:19 +0200)]
shell-app: Consider desktop actions in can_open_new_window()
We currently only consider a remote "app.new-window" action when running,
but not a fixed "new-window" action in the .desktop file. The latter is
clearly useful as well, in particular as open_new_window() already does,
so add it.
We start with a dim factor of 0, so the syncEnabled() call in the
constructor will always disable the effect. Just create the effect
disabled and save the method call.
barLevel: Don't reset value on overview-start changes
While it makes sense to cap the current value to a new maximum value,
I can't think of a good reason why changing the overdrive-start should
reset the current value to that.
The time computation isn't just unnecessary in that case, it's likely
wrong as well: If we don't have a valid allocation, we may well end
up with a negative value, NaN or Infinity.
Now that redisplaying is a lightweight operation that only
adds and removes what changed, we can not be concerned about
redisplaying on folder changes.
Redisplaying will be necessary when custom order in the app
grid is implemented, in order to update not only which icons
are hidden, but also their position.
FolderView and AllView currently check if the item is
present in the BaseAppView._items map, in order to avoid
adding the same icon multiple times.
Now that BaseAppView._loadApps() has a different role --
it returns a list with all app icons, and BaseAppView
diffs with the current list of app icons -- checking the
BaseAppView._items map is wrong.
Make sure there are no duplicated items in the temporary
array returned by all _loadApps() implementations. Remove
the now unused BaseAppView.hasItem() method.
BaseAppView currently removes all icons, and readds them, every
time the list of app icons needs to be redisplayed. In order to
allow animating app icon positions in the future, however, we
cannot destroy the actors of the app icons.
Previous commits paved the way for us to do differential loading,
i.e. add only the icons that were added, and remove only what was
removed.
Make the BaseAppView effectively implement differential loading.
The BaseAppView.removeAll() method is removed, since we do not
remove all icons anymore. BaseAppView._loadApps() now returns an
array with the new apps, instead of putting them directly at the
BaseAppView lists.
Now that the three views follow the exact same loading routine
(remove all + load apps + load grid), we don't need each view
call loadGrid() directly anymore.
This is an important step in order to animate adding and removing
icons, since now we can diff old and new app icons properly.
Move all calls to BaseAppView.loadGrid() to a single one after
BaseAppView._loadApps(). Also add the underscore prefix, since
this is now considered a protected function.
frequentView: Use BaseAppView.addItem() and loadGrid()
FrequentView is another view that is slightly not unified with how
BaseAppView expects subclasses to load app icons. Instead of using
BaseAppView.addItem() and then calling BaseAppview.loadGrid(), it
adds the app icons directly to the icon grid.
Make FrequentView add icons using BaseAppview.addItem(), and load
the icons using BaseAppView.loadGrid().
projects / gnome-shell.git / log